tools/backup-projects.sh (2)

427-427: Permission claim in message is asserted, not measured

(permissions: 0600) is hardcoded based on the umask 077 assumption, but is not verified. Under normal execution this is always correct; however, if the zip binary is wrapped or something else modifies the file after creation, the message would silently lie. Consider reading the actual mode with stat:

🔍 Optional: verify before asserting

-        say "Archive created: $archive_size (permissions: 0600)"
+        local archive_perms
+        archive_perms=$(stat -c "%a" "$archive_path" 2>/dev/null || stat -f "%OLp" "$archive_path" 2>/dev/null)
+        say "Archive created: $archive_size (permissions: ${archive_perms:-0600})"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/backup-projects.sh` at line 427, The message currently hardcodes
"(permissions: 0600)" after archive creation; instead read the actual file mode
and report it. After the archive is created, call stat to get its mode (e.g.,
stat -c '%a' "$archive" or fallback to stat -f '%Lp' "$archive" for BSD/macOS)
and store it (e.g., archive_mode), then change the say invocation to use
"$archive_size" and the queried "$archive_mode" rather than the hardcoded 0600;
reference the existing say call and the archive variable used when creating the
zip so the message always reflects the real file permissions.

---

344-347: mkdir -p + chmod creates a brief TOCTOU window; the proposed install fix does not solve the intermediate directory issue

The original concern about TOCTOU is valid: mkdir -p creates the directory with the default umask (typically 0755), then chmod 700 tightens it. However, the proposed fix using install -d -m 700 does not actually address the intermediate directory problem.

According to GNU coreutils documentation, install -d -m MODE does not apply the mode to parent directories—they are always created with 0755 regardless of -m. BSD install on macOS does not document this behavior, making it unreliable.

For this script, the practical risk is low:

• The TOCTOU window is very brief (milliseconds on a single-user machine).
• Intermediate directories being 0755 is acceptable since the final backups/ directory is 0700, which prevents traversal by other users even if parents are readable.

If you want to address both concerns, a more portable approach is to create the directory tree with secure permissions atomically:

Alternative: atomic directory creation with umask

-        mkdir -p "$BACKUP_TEMP_DIR"
-        chmod 700 "$BACKUP_TEMP_DIR"
-        mkdir -p "$LOG_DIR"
-        chmod 700 "$LOG_DIR"
+        ( umask 077; mkdir -p "$BACKUP_TEMP_DIR" )
+        ( umask 077; mkdir -p "$LOG_DIR" )

Alternatively, accept the current approach as sufficient for a single-user backup utility where the parent hierarchy is under $HOME.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/backup-projects.sh` around lines 344 - 347, The mkdir + chmod sequence
for BACKUP_TEMP_DIR and LOG_DIR creates a brief TOCTOU window; to eliminate it
portably, save the current umask, set umask to 077 (so newly created directories
are 0700), call mkdir -p "$BACKUP_TEMP_DIR" and mkdir -p "$LOG_DIR", then
immediately restore the saved umask; keep the chmod 700 as a safe fallback after
restore in case the directories already existed with different perms. Ensure you
reference and modify the existing mkdir -p/ chmod 700 uses for BACKUP_TEMP_DIR
and LOG_DIR and restore umask even on error (use a trap or ensure restore
happens).